home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-07-26 | 125.9 KB | 2,860 lines |
-
-
-
-
-
-
- Network Working Group P. Francis
- Request for Comments: 1621 NTT
- Category: Informational May 1994
-
-
- Pip Near-term Architecture
-
- Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- Preamble
-
- During 1992 and 1993, the Pip internet protocol, developed at
- Belclore, was one of the candidate replacments for IP. In mid 1993,
- Pip was merged with another candidate, the Simple Internet Protocol
- (SIP), creating SIPP (SIP Plus). While the major aspects of Pip--
- particularly its distinction of identifier from address, and its use
- of the source route mechanism to achieve rich routing capabilities--
- were preserved, many of the ideas in Pip were not. The purpose of
- this RFC and the companion RFC "Pip Header Processing" are to record
- the ideas (good and bad) of Pip.
-
- This document references a number of Pip draft memos that were in
- various stages of completion. The basic ideas of those memos are
- presented in this document, though many details are lost. The very
- interested reader can obtain those internet drafts by requesting them
- directly from me at <francis@cactus.ntt.jp>.
-
- The remainder of this document is taken verbatim from the Pip draft
- memo of the same title that existed when the Pip project ended. As
- such, any text that indicates that Pip is an intended replacement for
- IP should be ignored.
-
- Abstract
-
- Pip is an internet protocol intended as the replacement for IP
- version 4. Pip is a general purpose internet protocol, designed to
- evolve to all forseeable internet protocol requirements. This
- specification describes the routing and addressing architecture for
- near-term Pip deployment. We say near-term only because Pip is
- designed with evolution in mind, so other architectures are expected
- in the future. This document, however, makes no reference to such
- future architectures.
-
-
-
-
-
- Francis [Page 1]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Table of Contents
-
- 1. Pip Architecture Overview ................................... 4
- 1.1 Pip Architecture Characteristics ........................... 4
- 1.2 Components of the Pip Architecture ......................... 5
-
- 2. A Simple Example ............................................ 6
-
- 3. Pip Overview ................................................ 7
-
- 4. Pip Addressing .............................................. 9
- 4.1 Hierarchical Pip Addressing ................................ 9
- 4.1.1 Assignment of (Hierarchical) Pip Addresses ............... 12
- 4.1.2 Host Addressing .......................................... 14
- 4.2 CBT Style Multicast Addresses .............................. 15
- 4.3 Class D Style Multicast Addresses .......................... 16
- 4.4 Anycast Addressing ......................................... 16
-
- 5. Pip IDs ..................................................... 17
-
- 6. Use of DNS .................................................. 18
- 6.1 Information Held by DNS .................................... 19
- 6.2 Authoritative Queries in DNS ............................... 20
-
- 7. Type-of-Service (TOS) (or lack thereof) ..................... 21
-
- 8. Routing on (Hierarchical) Pip Addresses ..................... 22
- 8.1 Exiting a Private Domain ................................... 23
- 8.2 Intra-domain Networking .................................... 24
-
- 9. Pip Header Server ........................................... 25
- 9.1 Forming Pip Headers ........................................ 25
- 9.2 Pip Header Protocol (PHP) .................................. 27
- 9.3 Application Interface ...................................... 27
-
- 10. Routing Algorithms in Pip .................................. 28
- 10.1 Routing Information Filtering ............................. 29
-
- 11. Transition ................................................. 30
- 11.1 Justification for Pip Transition Scheme ................... 31
- 11.2 Architecture for Pip Transition Scheme .................... 31
- 11.3 Translation between Pip and IP packets .................... 33
- 11.4 Translating between PCMP and ICMP ......................... 34
- 11.5 Translating between IP and Pip Routing Information ........ 34
- 11.6 Old TCP and Application Binaries in Pip Hosts ............. 34
- 11.7 Translating between Pip Capable and non-Pip Capable DNS
- Servers ................................................... 35
-
-
-
-
- Francis [Page 2]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 12. Pip Address and ID Auto-configuration ...................... 37
- 12.1 Pip Address Prefix Administration ......................... 37
- 12.2 Host Autoconfiguration .................................... 38
- 12.2.1 Host Initial Pip ID Creation ............................ 38
- 12.2.2 Host Pip Address Assignment ............................. 39
- 12.2.3 Pip ID and Domain Name Assignment ....................... 39
-
- 13. Pip Control Message Protocol (PCMP) ........................ 40
-
- 14. Host Mobility .............................................. 42
- 14.1 PCMP Mobile Host message .................................. 43
- 14.2 Spoofing Pip IDs .......................................... 44
-
- 15. Public Data Network (PDN) Address Discovery ................ 44
- 15.1 Notes on Carrying PDN Addresses in NSAPs .................. 46
-
- 16. Evolution with Pip ......................................... 46
- 16.1 Handling Directive (HD) and Routing Context (RC) Evolution. 49
- 16.1.1 Options Evolution ....................................... 50
- References ..................................................... 51
- Security Considerations ........................................ 51
- Author's Address ............................................... 51
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Francis [Page 3]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Introduction
-
- Pip is an internet protocol intended as the replacement for IP
- version 4. Pip is a general purpose internet protocol, designed to
- handle all forseeable internet protocol requirements. This
- specification describes the routing and addressing architecture for
- near-term Pip deployment. We say near-term only because Pip is
- designed with evolution in mind, so other architectures are expected
- in the future. This document, however, makes no reference to such
- future architectures (except in that it discusses Pip evolution in
- general).
-
- This document gives an overall picture of how Pip operates. It is
- provided primarily as a framework within which to understand the
- total set of documents that comprise Pip.
-
- 1. Pip Architecture Overview
-
- The Pip near-term architecture is an incremental step from IP. Like
- IP, near-term Pip is datagram. Pip runs under TCP and UDP. DNS is
- used in the same fashion it is now used to distribute name to Pip
- Address (and ID) mappings. Routing in the near-term Pip architecture
- is hop-by-hop, though it is possible for a host to create a domain-
- level source route (for policy reasons).
-
- Pip Addresses have more hierarchy than IP, thus improving scaling on
- one hand, but introducing additional addressing complexities, such as
- multiple addresses, on the other. Pip, however, uses hierarchical
- addresses to advantage by making them provider-based, and using them
- to make policy routing (in this case, provider selection) choices.
- Pip also provides mechanisms for automatically assigning provider
- prefixes to hosts and routers in domains. This is the main
- difference between the Pip near-term architecture and the IP
- architecture. (Note that in the remainder of this paper, unless
- otherwise stated, the phrase "Pip architecture" refers to the near-
- term Pip architecture described herein.)
-
- 2. Pip Architecture Characteristics
-
- The proposed architecture for near-term Pip has the following
- characteristics:
-
- 1. Provider-rooted hierarchical addresses.
-
- 2. Automatic domain-wide address prefix assignment.
-
- 3. Automatic host address and ID assignment.
-
-
-
-
- Francis [Page 4]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 4. Exit provider selection.
-
- 5. Multiple defaults routing (default routing, but to multiple exit
- points).
-
- 6. Equivalent of IP Class D style addressing for multicast.
-
- 7. CBT style multicast.
-
- 8. "Anycast" addressing (route to one of a group, usually the
- nearest).
-
- 9. Providers support forwarding on policy routes (but initially will
- not provide the support for sources to calculate policy routes).
-
- 10. Mobile hosts.
-
- 11. Support for routing across large Public Data Networks (PDN).
-
- 12. Inter-operation with IP hosts (but, only within an IP-address
- domain where IP addresses are unique). In particular, an IP
- address can be explicitly carried in a Pip header.
-
- 13. Operation with existing transport and application binaries
- (though if the application contains IP context, like FTP, it may
- only work within a domain where IP addresses are unique).
-
- 14. Mechanisms for evolving Pip beyond the near-term architecture.
-
- 1.2 Components of the Pip Architecture
-
- The Pip Architecture consists of the following five systems:
-
- 1. Host (source and sink of Pip packets)
-
- 2. Router (forwards Pip packets)
-
- 3. DNS
-
- 4. Pip/IP Translator
-
- 5. Pip Header Server (formats Pip headers)
-
- The first three systems exist in the IP architecture, and require no
- explanation here. The fourth system, the Pip/IP Translator, is
- required solely for the purpose of inter-operating with current IP
- systems. All Pip routers are also Pip/IP translators.
-
-
-
-
- Francis [Page 5]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- The fifth system, the Pip Header Server, is new. Its function is to
- format Pip headers on behalf of the source host (though initially
- hosts will be able to do this themselves). This use of the Pip
- Header Server will increase as policy routing becomes more
- sophisticated (moves beyond near-term Pip Architecture capabilities).
-
- To handle future evolution, a Pip Header Server can be used to
- "spoon-feed" Pip headers to old hosts that have not been updated to
- understand new uses of Pip. This way, the probability that the
- internet can evolve without changing all hosts is increased.
-
- 2. A Simple Example
-
- A typical Pip "exchange" is as follows: An application initiates an
- exchange with another host as identified by a domain name. A request
- for one or more Pip Headers, containing the domain name of the
- destination host, goes to the Pip Header Server. The Pip Header
- Server generates a DNS request, and receive back a Pip ID, multiple
- Pip Addresses, and possibly other information such as a mobile host
- server or a PDN address. Given this information, plus information
- about the source host (its Pip Addresses, for instance), plus
- optionally policy information, plus optionally topology information,
- the Pip Header Server formats an ordered list of valid Pip headers
- and give these to the host. (Note that if the Pip Header Server is
- co-resident with the host, as will be common initially, the host
- behavior is similar to that of an IP host in that a DNS request comes
- from the host, and the host forms a Pip header based on the answer
- from DNS.)
-
- The source host then begins to transmit Pip packets to the
- destination host. If the destination host is an IP host, then the
- Pip packet is translated into an IP packet along the way. Assuming
- that the destination host is a Pip host, however, the destination
- host uses the destination Pip ID alone to determine if the packet is
- destined for it. The destination host generates a return Pip header
- based either on information in the received Pip header, or the
- destination host uses the Pip ID of the source host to query the Pip
- Header Server/DNS itself. The latter case involves more overhead,
- but allows a more informed decision about how to return packets to
- the originating host.
-
- If either host is mobile, and moves to a new location, thus getting a
- new Pip Address, it informs the other host of its new address
- directly. Since host identification is based on the Pip ID and not
- the Pip Address, this doesn't cause transport level to fail. If both
- hosts are mobile and receive new Pip Addresses at the same time (and
- thus cannot exchange packets at all), then they can query each
- other's respective mobile host servers (learned from DNS). Note that
-
-
-
- Francis [Page 6]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- keeping track of host mobility is completely confined to hosts.
- Routers never get involved in tracking mobile hosts (though naturally
- they are involved in host discovery and automatic host address
- assignment).
-
- 3. Pip Overview
-
- Here, a brief overview of the Pip protocol is given. The reader is
- encouraged to read [2] for a complete description.
-
- The Pip header is divided into three parts:
-
- Initial Part
- Transit Part
- Options Part
-
- The Initial Part contains the following fields:
-
- Version Number
- Options Offset, OP Contents, Options Present (OP)
- Packet SubID
- Protocol
- Dest ID
- Source ID
- Payload Length
- Host Version
- Payload Offset
- Hop Count
-
- All of the fields in the Initial Part are of fixed length. The
- Initial Part is 8 32-bit words in length.
-
- The Version Number places Pip as a subsequent version of IP. The
- Options Offset, OP Contents, and Options Present (OP) fields tell how
- to process the options. The Options Offset tells where the options
- are The OP tells which of up to 8 options are in the options part, so
- that the Pip system can efficiently ignore options that don't pertain
- to it. The OP Contents is like a version number for the OP field.
- It allows for different sets of the (up to 8) options.
-
- The Packet SubID is used to relate a received PCMP message to a
- previously sent Pip packet. This is necessary because, since routers
- in Pip can tag packets, the packet returned to a host in a PCMP
- message may not be the same as the packet sent. The Payload Length
- and Protocol take the place of IP's Total Length and Protocol fields
- respectively. The Dest ID identifies the destination host, and is
- not used for routing, except for where the final router on a LAN uses
- ARP to find the physical address of the host identified by the dest
-
-
-
- Francis [Page 7]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- ID. The Source ID identifies the source of the packet. The Host
- Version tells what control algorithms the host has implemented, so
- that routers can respond to hosts appropriately. This is an
- evolution mechanism. The Hop Count is similar to IP's Time-to-Live.
-
- The Transit Part contains the following fields:
-
- Transit Part Offset
- HD Contents
- Handling Directive (HD)
- Active FTIF
- RC Contents
- Routing Context (RC)
- FTIF Chain (FTIF = Forwarding Table Index Field)
-
- Except for the FTIF Chain, which can have a variable number of 16-bit
- FTIF fields, the fields in the Transit Part are of fixed length, and
- are three 32-bit words in length.
-
- The Transit Part Offset gives the length of the Transit Part. This
- is used to determine the location of the subsequent Transit Part (in
- the case of Transit Part encapsulation).
-
- The Handling Directive (HD) is a set of subfields, each of which
- indicates a specific handling action that must be executed on the
- packet. Handling directives have no influence on routing. The HD
- Contents field indicates what subfields are in the Handling
- Directive. This allows the definition of the set of handling
- directives to evolve over time. Example handling directives are
- queueing priority, congestion experienced bit, drop priority, and so
- on.
-
- The remaining fields comprise the Routing Directive. This is where
- the routing decision gets made. The basic algorithm is that the
- router uses the Routing Context to choose one of multiple forwarding
- tables. The Active FTIF indicates which of the FTIFs to retrieve,
- which is then used as an index into the forwarding table, which
- either instructs the router to look at the next FTIF, or returns the
- forwarding information.
-
- Examples of Routing Context uses are; to distinguish address families
- (multicast vs. unicast), to indicate which level of the hierarchy a
- packet is being routed at, and to indicate a Type of Service. In the
- near-term architecture, the FTIF Chain is used to carry source and
- destination hierarchical unicast addresses, policy route fragments,
- multicast addresses (all-of-group), and anycast (one-of-group)
- addresses. Like the OP Contents and HD Contents fields, the RC
- Contents field indicates what subfields are in the Routing Context.
-
-
-
- Francis [Page 8]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- This allows the definition of the Routing Context to evolve over
- time.
-
- The Options Part contains the options. The options are preceded by
- an array of 8 fields that gives the offset of each of up to 8
- options. Thus, a particular option can be found without a serial
- search of the list of options.
-
- 4. Pip Addressing
-
- Addressing is the core of any internet architecture. Pip Addresses
- are carried in the Routing Directive (RD) of the Pip header (except
- for the Pip ID, which in certain circumstances functions as part of
- the Pip Address). Pip Addresses are used only for routing packets.
- They do not identify the source and destination of a Pip packet. The
- Pip ID does this. Here we describe and justify the Pip Addressing
- types.
-
- There are four Pip Address types [11]. The hierarchical Pip Address
- (referred to simply as the Pip Address) is used for scalable unicast
- and for the unicast part of a CBT-style multicast and anycast. The
- multicast part of a CBT-style multicast is the second Pip address
- type. The third Pip address type is class-D style multicast. The
- fourth type of Pip address is the so-called "anycast" address. This
- address causes the packet to be forwarded to one of a class of
- destinations (such as, to the nearest DNS server).
-
- Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is,
- for the near-term Pip architecture) indicate which of four address
- families the FTIFs and Dest ID apply to. The values are:
-
- Value Address Family
- ----- --------------
- 00 Hierarchical Unicast Pip Address
- 01 Class D Style Multicast Address
- 10 CBT Style Multicast Address
- 11 Anycast Pip Address
-
- The remaining bits are defined differently for different address
- families, and are defined in the following sections.
-
- 4.1 Hierarchical Pip Addressing
-
- The primary purpose of a hierarchical address is to allow better
- scaling of routing information, though Pip also uses the "path"
- information latent in hierarchical addresses for making provider
- selection (policy routing) decisions.
-
-
-
-
- Francis [Page 9]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- The Pip Header encodes addresses as a series of separate numbers, one
- number for each level of hierarchy. This can be contrasted to
- traditional packet encodings of addresses, which places the entire
- address into one field. Because of Pip's encoding, it is not
- necessary to specify a format for a Pip Address as it is with
- traditional addresses (for instance, the SIP address is formatted
- such that the first so-many bits are the country/metro code, the next
- so-many bits are the site/subscriber, and so on). Pip's encoding
- also eliminates the "cornering in" effect of running out of space in
- one part of the hierarchy even though there is plenty of room in
- another. No "field sizing" decisions need be made at all with Pip
- Addresses. This makes address assignment easier and more flexible
- than with traditional addresses.
-
- Pip Addresses are carried in DNS as a series of numbers, usually with
- each number representing a layer of the hierarchy [1], but optionally
- with the initial number(s) representing a "route fragment" (the tail
- end of a policy route--a source route whose elements are providers).
- The route fragments would be used, for instance, when the destination
- network's directly attached (local access) provider is only giving
- access to other (long distance) providers, but the important
- provider-selection policy decision has to do the long distance
- providers.
-
- The RC for (hierarchical) Pip Addresses is defined as:
-
- bits meaning
- ---- -------
- 0,1 Pip Address (= 00)
- 2,3 level
- 4,5 metalevel
- 6 exit routing type
-
- The level and metalevel subfields are used to indicate what level of
- the hierarchy the packet is currently at (see section 8). The exit
- routing type subfield is used to indicate whether host-driven (hosts
- decide exit provider) or router-driven (routers decide exit provider)
- exit routing is in effect (see section 8.1).
-
- Each FTIF in the FTIF Chain is 16 bits in length. The low-order part
- of each FTIF in a (hierarchical unicast) Pip Address indicates the
- relationship of the FTIF with the next FTIF. The three relators are
- Vertical, Horizontal, and Extension. The Vertical and Horizontal
- relators indicate if the subsequent FTIF is hierarchically above or
- below (Vertical) or hierarchically unrelated (Horizontal). The
- Extension relator is used to encode FTIF values longer than 16 bits.
-
-
-
-
-
- Francis [Page 10]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- FTIF values 0 - 31 are reserved for special purposes. That is, they
- cannot be assigned to normal hierarchical elements. FTIF value 1 is
- defined as a flag to indicate a switch from the unicast phase of
- packet forwarding to the anycast phase of packet forwarding.
-
- Note that Pip Addresses do not need to be seen by protocol layers
- above Pip (though layers above Pip can provide a Pip Address if
- desired). Transport and above use the Pip ID to identify the source
- and destination of a Pip packet. The Pip layer is able to map the
- Pip IDs (and other information received from the layer above, such as
- QOS) into Pip Addresses.
-
- The Pip ID can serve as the lowest level of a Pip Address. While
- this "bends the principal" of separating Pip Addressing from Pip
- Identification, it greatly simplifies dynamic host address
- assignment. The Pip ID also serves as a multicast ID. Unless
- otherwise stated, the term "Pip Address" refers to just the part in
- the Routing Directive (that is, excludes the Pip ID).
-
- Pip Addresses are provider-rooted (as opposed to geographical). That
- is, the top-level of a Pip Address indicates a network service
- provider (even when the service provided is not Pip). (A
- justification of using provider-rooted rather than geographical
- addresses is given in [12].)
-
- Thus, the basic form of a Pip address is:
-
- providerPart,subscriberPart
-
- where both the providerPart and subscriberPart can have multiple
- layers of hierarchy internally.
-
- A subscriber may be attached to multiple providers. In this case, a
- host can end up with multiple Pip Addresses by virtue of having
- multiple providerParts:
-
- providerPart1,subscriberPart
- providerPart2,subscriberPart
- providerPart3,subscriberPart
-
- This applies to the case where the subscriber network spans many
- different provider areas, for instance, a global corporate network.
- In this case, some hosts in the global corporate network will have
- certain providerParts, and other hosts will have others. The
- subscriberPart should be assigned such that routing can successfully
- take place without a providerPart in the destination Pip Address of
- the Pip Routing Directive (see section 8.2).
-
-
-
-
- Francis [Page 11]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Note that, while there are three providerParts shown, there is only
- one subscriberPart. Internal subscriber numbering should be
- independent of the providerPart. Indeed, with the Pip architecture,
- it is possible to address internal packets without including any of
- the providerPart of the address.
-
- Top-level Pip numbers can be assigned to subscriber networks as well
- as to providers.
-
- privatePart,subscriberPart
-
- In this case, however, the top-level number (privatePart) would not
- be advertised globally. The purpose of such an assignment is to give
- a private network "ownership" of a globally unique Pip Address space.
- Note that the privatePart is assigned as an extended FTIF (that is,
- from numbers greater than 2^15). Because the privatePart is not
- advertised globally, and because internal packets do not need the
- prefix (above the subscriberPart), the privatePart actually never
- appears in a Pip packet header.
-
- Pip Addresses can be prepended with a route fragment. That is, one
- or more Pip numbers that are all at the top of the hierarchy.
-
- longDistanceProvider.localAccessProvider.subscriber
- (top-level) (top-level) (next level)
-
- This is useful, for instance, when the subscriber's directly attached
- provider is a "local access" provider, and is not advertised
- globally. In this case, the "long distance" provider is prepended to
- the address even though the local access provider number is enough to
- provide global uniqueness.
-
- Note that no coordination is required between the long distance and
- local access providers to form this address. The subscriber with a
- prefix assigned to it by the local access provider can autonomously
- form and use this address. It is only necessary that the long
- distance provider know how to route to the local access provider.
-
- 4.1.1 Assignment of (Hierarchical) Pip Addresses
-
- Administratively, Pip Addresses are assigned as follows [3]. There
- is a root Pip Address assignment authority. Likely choices for this
- are IANA or ISOC. The root authority assigns top-level Pip Address
- numbers. (A "Pip Address number" is the number at a single level of
- the Pip Address hierarchy. A Pip Address prefix is a series of
- contiguous Pip Address numbers, starting at the top level but not
- including the entire Pip Address. Thus, the top-level prefix is the
- same thing as the top-level number.)
-
-
-
- Francis [Page 12]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Though by-and-large, and most importantly, top-level assignments are
- made to providers, each country is given an assignment, each existing
- address space (such as E.164, X.121, IP, etc.) is given an
- assignment, and private networks can be given assignments. Thus,
- existing addresses can be grandfathered in. Even if the top-level
- Pip address number is an administrative rather than topological
- assignment, the routing algorithm still advertises providers at the
- top (provider) level of routing. That is, routing will advertise
- enough levels of hierarchy that providers know how to route to each
- other.
-
- There must be some means of validating top-level number requests from
- providers (basically, those numbers less than 2^15). That is, top-
- level assignments must be made only to true providers. While
- designing the best way to do this is outside the scope of this
- document, it seems off hand that a reasonable approach is to charge
- for the top-level prefixes. The charge should be enough to
- discourage non-serious requests for prefixes, but not so much that it
- becomes an inhibitor to entry in the market. The charge might
- include a yearly "rent", and top-level prefixes could be reclaimed
- when they are no longer used by the provider. Any profit made from
- this activity could be used to support the overall role of number
- assignment. Since roughly 32,000 top-level assignments can be made
- before having to increase the FTIF size in the Pip header from 16
- bits to 32 bits, it is envisioned that top-level prefixes will not be
- viewed as a scarce resource.
-
- After a provider obtains a top-level prefix, it becomes an assignment
- authority with respect to that particular prefix. The provider has
- complete control over assignments at the next level down (the level
- below the top-level). The provider may either assign top-level minus
- one prefixes to subscribers, or preferably use that level to provide
- hierarchy within the provider's network (for instance, in the case
- where the provider has so many subscribers that keeping routing
- information on all of them creates a scaling problem). It is
- envisioned that the subscriber will have complete control over number
- assignments made at levels below that of the prefix assigned it by
- the provider.
-
- Assigning top level prefixes directly to providers leaves the number
- of top-level assignments open-ended, resulting in the possibility of
- scaling problems at the top level. While it is expected that the
- number of providers will remain relatively small (say less than 10000
- globally), this can't be guaranteed. If there are more providers
- than top-level routing can handle, it is likely that many of these
- providers will be "local access" providers--providers whose role is
- to give a subscriber access to multiple "long-distance" providers.
- In this case, the local access providers need not appear at the top
-
-
-
- Francis [Page 13]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- level of routing, thus mitigating the scaling problem at that level.
-
- In the worst case, if there are too many top-level "long-distance"
- providers for top-level routing to handle, a layer of hierarchy above
- the top-level can be created. This layer should probably conform to
- some policy criteria (as opposed to a geographical criteria). For
- instance, backbones with similar access restrictions or type-of-
- service can be hierarchically clustered. Clustering according to
- policy criteria rather than geographical allows the choice of address
- to remain an effective policy routing mechanism. Of course, adding a
- layer of hierarchy to the top requires that all systems, over time,
- obtain a new providerPart prefix. Since Pip has automatic prefix
- assignment, and since DNS hides addresses from users, this is not a
- debilitating problem.
-
- 4.1.2 Host Addressing
-
- Hosts can have multiple Pip Addresses. Since Pip Addresses are
- topologically significant, a host has multiple Pip Addresses because
- it exists in multiple places topologically. For instance, a host can
- have multiple Pip addresses because it can be reached via multiple
- providers, or because it has multiple physical interfaces. The
- address used to reach the host influences the path to the host.
-
- Locally, Pip Addressing is similar to IP Addressing. That is, Pip
- prefixes are assigned to subnetworks (where the term subnetwork here
- is meant in the OSI sense. That is, it denotes a network operating
- at a lower layer than the Pip layer, for instance, a LAN). Thus, it
- is not necessary to advertise individual hosts in routing updates--
- routers only need to advertise and store routes to subnetworks.
-
- Unlike IP, however, a single subnetwork can have multiple prefixes.
- (Strictly speaking, in IP a single subnetwork can have multiple
- prefixes, but a host may not be able to recognize that it can reach
- another host on the same subnetwork but with a different prefix
- without going through a router.)
-
- There are two styles of local Pip Addressing--one where the Pip
- Address denotes the host, and another where the Pip Address denotes
- only the destination subnetwork. The latter style is called ID-
- tailed Pip Addressing. With ID-tailed Pip Addresses, the Pip ID is
- used by the last router to forward the packet to the host. It is
- expected that ID-tailed Pip Addressing is the most common, because it
- greatly eases address administration.
-
- (Note that the Pip Routing Directive can be used to route a Pip
- packet internal to a host. For instance, the RD can be used to
- direct a packet to a device in a host, or even a certain memory
-
-
-
- Francis [Page 14]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- location. The use of the RD for this purpose is not part of this
- near-term Pip architecture. We note, however, that this use of the
- RD could be locally done without effecting any other Pip systems.)
-
- When a router receives a Pip packet and determines that the packet is
- destined for a host on one of its' attached subnetworks (by examining
- the appropriate FTIF), it then examines the destination Pip ID (which
- is in a fixed position) and forwards based on that. If it does not
- know the subnetwork address of the host, then it ARPs, using the Pip
- ID as the "address" in the ARP query.
-
- 4.2 CBT Style Multicast Addresses
-
- When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10,
- the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast.
- The remainder of the bits are defined as follows:
-
-
- bits meaning
- ---- -------
- 0,1 CBT Multicast (= 10)
- 2,3 level
- 4,5 metalevel
- 6 exit routing type
- 7 on-tree bit
- 8,9 scoping
-
-
- With CBT (Core-based Tree) multicast, there is a single multicast
- tree connecting the members (recipients) of the multicast group (as
- opposed to Class-D style multicast, where there is a tree per
- source). The tree emanates from a single "core" router. To transmit
- to the group, a packet is routed to the core using unicast routing.
- Once the packet reaches a router on the tree, it is multicast using a
- group ID.
-
- Thus, the FTIF Chain for CBT multicast contains the (Unicast)
- Hierarchical Pip Address of the core router. The Dest ID field
- contains the group ID.
-
- A Pip CBT packet, then, has two phases of forwarding, a unicast phase
- and a multicast phase. The "on-tree" bit of the RC indicates which
- phase the packet is in. While in the unicast phase, the on-tree bit
- is set to 0, and the packet is forwarded similarly to Pip Addresses.
- During this phase, the scoping bits are ignored.
-
-
-
-
-
-
- Francis [Page 15]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Once the packet reaches the multicast tree, it switches to multicast
- routing by changing the on-tree bit to 1 and using the Dest ID group
- address for forwarding. During this phase, bits 2-6 are ignored.
-
- 4.3 Class D Style Multicast Addresses
-
- When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01,
- the FTIF and Dest ID indicate Class D style multicast. The remainder
- of the RC is defined as:
-
-
- bits meaning
- ---- -------
- 0,1 Class D Style Multicast (= 01)
- 2-5 Scoping
-
-
- By "class D" style multicast, we mean multicast using the algorithms
- developed for use with Class D addresses in IP (class D addresses are
- not used per se). This style of routing uses both source and
- destination information to route the packet (source host address and
- destination multicast group).
-
- For Pip, the FTIF Chain holds the source Pip Address, in order of
- most significant hierarchy level first. The reason for putting the
- source Pip Address rather than the Source ID in the FTIF Chain is
- that use of the source Pip Address allows the multicast routing to
- take advantage of the hierarchical source address, as is being done
- with IP. The Dest ID field holds the multicast group. The Routing
- Context indicates Class-D style multicast. All routers must first
- look at the FTIF Chain and Dest ID field to route the packet on the
- tree.
-
- Bits 2 through 5 of the RC are the scoping bits.
-
- 4.4 Anycast Addressing
-
- When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11,
- the FTIF and Dest ID indicate Anycast addressing. The remainder of
- the RC is defined as:
-
-
-
-
-
-
-
-
-
-
-
- Francis [Page 16]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- bits meaning
- ---- -------
- 0,1 Anycast Address (= 11)
- 2,3 level
- 4,5 metalevel
- 6 exit routing type
- 7 anycast active
- 8,9 scoping
-
-
- With anycast routing, the packet is unicast, but to the nearest of a
- group of destinations. This type of routing is used by Pip for
- autoconfiguration. Other applications, such as discovery protocols,
- may also use anycast routing.
-
- Like CBT, Pip anycast has two phases of operation, in this case the
- unicast phase and the anycast phase. The unicast phase is for the
- purpose of getting the packet into a certain vicinity. The anycast
- phase is to forward the packet to the nearest of a group of
- destinations in that vicinity.
-
- Thus, the RC has both unicast and anycast information in it. During
- the unicast phase, the anycast active bit is set to 0, and the packet
- is forwarded according to the rules of Pip Addressing. The scoping
- bits are ignored.
-
- The switch from the unicast phase to the anycast phase is triggered
- by the presence of an FTIF of value 1 in the FTIF Chain. When this
- FTIF is reached, the anycast active bit is set to 1, the scoping bits
- take effect, and bits 2 through 6 are ignored. When in the anycast
- phase, forwarding is based on the Dest ID field.
-
- 5. Pip IDs
-
- The Pip ID is 64-bits in length [4].
-
- The basic role of the Pip ID is to identify the source and
- destination host of a Pip Packet. (The other role of the Pip ID is
- for allowing a router to find the destination host on the destination
- subnetwork.)
-
- This having been said, it is possible for the Pip ID to ultimately
- identify something in addition to the host. For instance, the Pip ID
- could identify a user or a process. For this to work, however, the
- Pip ID has to be bound to the host, so that as far as the Pip layer
- is concerned, the ID is that of the host. Any additional use of the
- Pip ID is outside the scope of this Pip architecture.
-
-
-
-
- Francis [Page 17]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- The Pip ID is treated as flat. When a host receives a Pip packet, it
- compares the destination Pip ID in the Pip header with its' own. If
- there is a complete match, then the packet has reached the correct
- destination, and is sent to the higher layer protocol. If there is
- not a complete match, then the packet is discarded, and a PCMP
- Invalid Address packet is returned to the originator of the packet
- [7].
-
- It is something of an open issue as to whether or not Pip IDs should
- contain significant organizational hierarchy information. Such
- information could be used for inverse DNS lookups and allowing a Pip
- packet to be associated with an organization. (Note that the use of
- the Pip ID alone for this purpose can be easily spoofed. By cross
- checking the Pip ID with the Pip Address prefix, spoofing is harder-
- -as hard as it is with IP--but still easy. Section 14.2 discusses
- methods for making spoofing harder still, without requiring
- encryption.)
-
- However, relying on organizational information in the Pip header
- generally complicates ID assignment. This complication has several
- ramifications. It makes host autoconfiguration of hosts harder,
- because hosts then have to obtain an assignment from some database
- somewhere (versus creating one locally from an IEEE 802 address, for
- instance). It means that a host has to get a new assignment if it
- changes organizations. It is not clear what the ramifications of
- this might be in the case of a mobile host moving through different
- organizations.
-
- Because of these difficulties, the use of flat Pip IDs is currently
- favored.
-
- Blocks of Pip ID numbers have been reserved for existing numbering
- spaces, such as IP, IEEE 802, and E.164. Pip ID numbers have been
- assigned for such special purposes such as "any host", "any router",
- "all hosts on a subnetwork", "all routers on a subnetwork", and so
- on. Finally, 32-bit blocks of Pip ID numbers have been reserved for
- each country, according to ISO 3166 country code assignments.
-
- 6. Use of DNS
-
- The Pip near-term architecture uses DNS in roughly the same style
- that it is currently used. In particular, the Pip architecture
- maintains the two fundamental DNS characteristics of 1) information
- stored in DNS does not change often, and 2) the information returned
- by DNS is independent of who requested it.
-
- While the fundamental use of DNS remains roughly the same, Pip's use
- of DNS differs from IP's use by degrees. First, Pip relies on DNS to
-
-
-
- Francis [Page 18]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- hold more types of information than IP [1]. Second, Pip Addresses in
- DNS are expected to change more often than IP addresses, due to
- reassignment of Pip Address prefixes (the providerPart). To still
- allow aggressive caching of DNS records in the face of more quickly
- changing addressing, Pip has a mechanism of indicating to hosts when
- an address is no longer assigned. This triggers an authoritative
- query, which overrides DNS caches. The mechanism consists of PCMP
- Packet Not Delivered messages that indicate explicitly that the Pip
- Address is invalid.
-
- In what follows, we first discuss the information contained in DNS,
- and then discuss authoritative queries.
-
- 6.1 Information Held by DNS
-
- The information contained in DNS for the Pip architecture is:
-
- 1. The Pip ID.
-
- 2. Multiple Pip Addresses
-
- 3. The destination's mobile host address servers.
-
- 4. The Public Data Network (PDN) addresses through which the
- destination can be reached.
-
- 5. The Pip/IP Translators through which the destination (if the
- destination is IP-only) can be reached.
-
- 6. Information about the providers represented by the destination's
- Pip addresses. This information includes provider name, the type
- of provider network (such as SMDS, ATM, or SIP), and access
- restrictions on the provider's network.
-
- The Pip ID and Addresses are the basic units of information required
- for carriage of a Pip packet.
-
- The mobile host address server tells where to send queries for the
- current address of a mobile Pip host. Note that usually the current
- address of the mobile host is conveyed by the mobile host itself,
- thus a mobile host server query is not usually required.
-
- The PDN address is used by the entry router of a PDN to learn the PDN
- address of the next hop router. The entry router obtains the PDN
- address via an option in the Pip packet. If there are multiple PDNs
- associated with a given Pip Address, then there can be multiple PDN
- addresses carried in the option. Note that the option is not sent on
- every packet, and that only the PDN entry router need examine the
-
-
-
- Francis [Page 19]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- option.
-
- The Pip/IP translator information is used to know how to translate an
- IP address into a Pip Address so that the packet can be carried
- across the Pip infrastructure. If the originating host is IP, then
- the first IP/Pip translator reached by the IP packet must query DNS
- for this information.
-
- The information about the destination's providers is used to help the
- "source" (either the source host or a Pip Header Server near the
- source host) format an appropriate Pip header with regards to
- choosing a Pip Address [14]. The choice of one of multiple Pip
- Addresses is essentially a policy routing choice.
-
- More detailed descriptions of the use of the information carried in
- DNS is contained in the relevant sections.
-
- 6.2 Authoritative Queries in DNS
-
- In general, Pip treats addresses as more dynamic entities than does
- IP. One example of this is how Pip Address prefixes change when a
- subscriber network attaches to a new provider. Pip also carries more
- information in DNS, any of which can change for various reasons.
- Thus, the information in DNS is more dynamic with Pip than with IP.
-
- Because of the increased reliance on DNS, there is a danger of
- increasing the load on DNS. This would be particularly true if the
- means of increasing DNS' dynamicity is by shortening the cache
- holding time by decreasing the DNS Time-to-Live (TTL). To counteract
- this trend, Pip provides explicit network layer (Pip layer) feedback
- on the correctness of address information. This allows Pip hosts to
- selectively over-ride cached DNS information by making an
- authoritative query. Through this mechanism, we actually hope to
- increase the cache holding time of DNS, thus improving DNS' scaling
- characteristics overall.
-
- The network layer feedback is in the form of a type of PCMP Packet
- Not Delivered (PDN) message that indicates that the address used is
- known to be out-of-date. Routers can be configured with this
- information, or it can be provided through the routing algorithm
- (when an address is decommissioned, the routing algorithm can
- indicate that this is the reason that it has become unreachable, as
- opposed to becoming "temporarily" unreachable through equipment
- failure).
-
- Pip hosts consider destination addresses to be in one of four states:
-
-
-
-
-
- Francis [Page 20]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 1. Unknown, but assumed to be valid.
-
- 2. Reachable (and therefore valid).
-
- 3. Unreachable and known to be invalid.
-
- 4. Unreachable, but weakly assumed to be valid.
-
- The first state exists before a host has attempted communication with
- another host. In this state, the host queries DNS as normal (that
- is, does not make an authoritative query).
-
- The second state is reached when a host has successfully communicated
- with another host. Once a host has reached this state, it can stay
- in it for an arbitrarily long time, including after the DNS TTL has
- expired. When in this state, there is no need to query DNS.
-
- A host enters the third state after a failed attempt at communicating
- with another host where the PCMP PND message indicates explicitly
- that the address is known to be invalid. In this case, the host
- makes an authoritative query to DNS whether or not the TTL has
- expired. It is this case that allows lengthy caching of DNS
- information while still allowing addresses to be reassigned
- frequently.
-
- A host enters the fourth state after a failed attempt at
- communicating with another host, but where the address is not
- explicitly known to be invalid. In this state, the host weakly
- assumes that the address of the destination is still valid, and so
- can requery DNS with a normal (non-authoritative) query.
-
- 7. Type-of-Service (TOS) (or lack thereof)
-
- One year ago it probably would have been adequate to define a handful
- (4 or 5) of priority levels to drive a simple priority FIFO queue.
- With the advent of real-time services over the Internet, however,
- this is no longer sufficient. Real-time traffic cannot be handled on
- the same footing as non-real-time. In particular, real-time traffic
- must be subject to access control so that excess real-time traffic
- does not swamp a link (to the detriment of other real-time and non-
- real-time traffic alike).
-
- Given that a consensus solution to real- and non-real-time traffic
- management in the internet does not exist, this version of the Pip
- near-term architecture does not specify any classes of service (and
- related queueing mechanisms). It is expected that Pip will define
- classes of service (primarily for use in the Handling Directive) as
- solutions become available.
-
-
-
- Francis [Page 21]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 8. Routing on (Hierarchical) Pip Addresses
-
- Pip forwarding in a single router is done based on one or a small
- number of FTIFs. What this means with respect to hierarchical Pip
- Addresses is that a Pip router is able to forward a packet based on
- examining only part of the Pip Address--often a single level.
-
- One advantage to encoding each level of the Pip Address separately is
- that it makes handling of addresses, for instance address assignment
- or managing multiple addresses, easier. Another advantage is address
- lookup speed--the entire address does not have to be examined to
- forward a packet (as is necessary, for instance, with traditional
- hierarchical address encoding). The cost of this, however, is
- additional complexity in keeping track of the active hierarchical
- level in the Pip header.
-
- Since Pip Addresses allow reuse of numbers at each level of the
- hierarchy, it is necessary for a Pip router to know which level of
- the hierarchy it is acting at when it retrieves an FTIF. This is
- done in part with a hierarchy level indicator in the Routing Context
- (RC) field. RC level is numbered from the top of the hierarchy down.
- Therefore, the top of the hierarchy is RC level = 0, the next level
- down is RC level = 1, and so on.
-
- The RC level alone, however, is not adequate to keep track of the
- appropriate level in all cases. This is because different parts of
- the hierarchy may have different numbers of levels, and elements of
- the hierarchy (such as a domain or an area) may exist in multiple
- parts of the hierarchy. Thus, a hierarchy element can be, say, level
- 3 under one of its parents and level 2 under another.
-
- To resolve this ambiguity, the topological hierarchy is superimposed
- with another set of levels--metalevels [11]. A metalevel boundary
- exists wherever a hierarchy element has multiple parents with
- different numbers of levels, or may with reasonable probability have
- multiple parents with different numbers of levels in the future.
-
- Thus, a metalevel boundary exists between a subscriber network and
- its provider. (Note that in general the metalevel represents a
- significant administrative boundary between two levels of the
- topological hierarchy. It is because of this administrative boundary
- that the child is likely to have multiple parents.) Lower metalevels
- may exist, but usually will not.
-
- The RC, then, contains a level and a metalevel indicator. The level
- indicates the number of levels from the top of the next higher
- metalevel. The top of the global hierarchy is metalevel 0, level 0.
- The next level down (for instance, the level that provides a level of
-
-
-
- Francis [Page 22]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- hierarchy within a provider) is metalevel 0, level 1. The first
- level of hierarchy under a provider is metalevel 1, level 0, and so
- on.
-
- To determine the RC level and RC metalevel in a transmitted Pip
- packet, a host (or Pip Header Server) must know where the metalevels
- are in its own Pip Addresses.
-
- The host compares its source Pip Address with the destination Pip
- Address. The highest Pip Address component that is different between
- the two addresses determines the level and metalevel. (No levels
- higher than this level need be encoded in the Routing Directive.)
-
- Neighbor routers are configured to know if there is a level or
- metalevel boundary between them, so that they can modify the RC level
- and RC metalevel in a transmitted packet appropriately.
-
- 8.1 Exiting a Private Domain
-
- The near-term Pip Architecture provides two methods of exit routing,
- that is, routing inter-domain Pip packets from a source host to a
- network service provider of a private domain [12,15]. In the first
- method, called transit-driven exit routing, the source host leaves
- the choice of provider to the routers. In the second method, called
- host-driven exit routing, the source host explicitly chooses the
- provider. In either method, it is possible to prevent internal
- routers from having to carry external routing information. The exit
- routing bit of the RC indicates which type of exit routing is in
- effect.
-
- With host-driven exit routing, it is possible for the host to choose
- a provider through which the destination cannot be reached. In this
- case, the host receives the appropriate PCMP Packet Not Delivered
- message, and may either fallback on transit-driven exit routing or
- choose a different provider.
-
- When using transit-driven exit routing, there are two modes of
- operation. The first, called destination-oriented, is used when the
- routers internal to a domain have external routing information, and
- the host has only one provider prefix. The second, called provider-
- oriented, is used when the routers internal to a domain do not have
- any external routing information or when the host has multiple
- provider prefixes. (With IP, this case is called default routing.
- In the case of IP, however, default routing does not allow an
- intelligent choice of multiple exit points.)
-
- With provider-oriented exit routing, the host arbitrarily chooses a
- source Pip Address (and therefore, a provider). (Note that if the
-
-
-
- Francis [Page 23]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Pip Header Server is tracking inter-domain routing, then it chooses
- the appropriate provider.) If the host chooses the wrong provider,
- then the border router will redirect the host to the correct provider
- with a PCMP Provider Redirect message.
-
- 8.2 Intra-domain Networking
-
- With intra-domain networking (where both source and destination are
- in the private network), there are two scenarios of concern. In the
- first, the destination address shares a providerPart with the source
- address, and so the destination is known to be intra-domain even
- before a packet is sent. In the second, the destination address does
- not share a providerPart with the source address, and so the source
- host doesn't know that the destination is reachable intra-domain.
- Note that the first case is the most common, because the private
- top-level number assignment acts as the common prefix even though it
- isn't advertised globally (see section 4.1).
-
- In the first case, the Pip Addresses in the Routing Directive need
- not contain the providerPart. Rather, it contains only the address
- part below the metalevel boundary. (A Pip Address in an FTIF Chain
- always starts at a metalevel boundary).
-
- For instance, if the source Pip Address is 1.2.3,4.5.6 and the
- destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be
- included for the destination address in the Routing Directive. (The
- comma "," in the address indicates the metalevel boundary between
- providerPart and subscriberPart.) The metalevel and level are set
- accordingly.
-
- In the second case, it is desirable to use the Pip Header Server to
- determine if the destination is intra-domain or inter-domain. The
- Pip Header Server can do this by monitoring intra-domain routing.
- (This is done by having the Pip Header Server run the intra-domain
- routing algorithm, but not advertise any destinations.) Thus, the Pip
- Header Server can determine if the providerPart can be eliminated
- from the address, as described in the last paragraph, or cannot and
- must conform to the rules of exit routing as described in the
- previous section.
-
- If the Pip Header Server does not monitor intra-domain routing,
- however, then the following actions occur. In the case of host-
- driven exit routing, the packet will be routed to the stated
- provider, and an external path will be used to reach an internal
- destination. (The moral here is to not use host-driven exit routing
- unless the Pip Header Server is privy to routing information, both
- internal and external.)
-
-
-
-
- Francis [Page 24]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- In the case of transit-driven exit routing, the packet sent by the
- host will eventually reach a router that knows that the destination
- is intra-domain. This router will forward the packet towards the
- destination, and at the same time send a PCMP Reformat Transit Part
- message to the host. This message tells the host how much of the Pip
- Address is needed to route the packet.
-
- 9. Pip Header Server
-
- Two new components of the Pip Architecture are the Pip/IP Translator
- and the Pip Header Server. The Pip/IP Translator is only used for
- transition from IP to Pip, and otherwise would not be necessary. The
- Pip Header Server, however, is a new architectural component.
-
- The purpose of the Pip Header Server is to form a Pip Header. It is
- useful to form the Pip header in a separate box because 1) in the
- future (as policy routing matures, for instance), significant amounts
- of information may be needed to form the Pip header--too much
- information to distribute to all hosts, and 2) it won't be possible
- to evolve all hosts at the same time, so the existence of a separate
- box that can spoon-feed Pip headers to old hosts is necessary. (It
- is impossible to guarantee that no modification of Pip hosts is
- necessary for any potential evolution, but being able to form the
- header in a server, and hand it to an outdated host, is a large step
- in the right direction.)
-
- (Note that policy routing architectures commonly if not universally
- require the use of some kind of "route server" for calculating policy
- routes. The Pip Header Server is, among other things, just this
- server. Thus, the Pip Header Server does not so much result from the
- fact that Pip itself is more complex than IP or other "IPv7"
- proposals. Rather, the Pip Header Server reflects the fact that the
- Pip Architecture has more functionality than ROAD architectures
- supported by the simpler proposals.)
-
- We note that for the near-term architecture hosts themselves will
- by-and-large have the capability of forming Pip headers. The
- exception to this will be the case where the Pip Header Server wishes
- to monitor inter-domain routing to enhance provider selection. Thus,
- the Pip Header Server role will be largely limited to evolution (see
- section 16).
-
- 9.1 Forming Pip Headers
-
- Forming a Pip header is more complex than forming an IP header
- because there are many more choices to make. At a minimum, one of
- multiple Pip Addresses (both source and destination) must be chosen
- [14]. In the near future, it will also be necessary to choose a TOS.
-
-
-
- Francis [Page 25]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- After DNS information about the destination has been received, the
- the following information is available to the Pip header formation
- function.
-
- 1. From DNS: The destination's providers (either directly connected
- or nearby enough to justify making a policy decision about), and
- the names, types, and access restrictions of those providers.
-
- 2. From the source host: The application type (and thus, the desired
- service), and the user access restriction classes.
-
- 3. From local configuration: The source's providers, and the names,
- types, and access restrictions of those providers.
-
- 4. Optionally from inter-domain routing: The routes chosen by
- inter-domain to all top level providers. (Note that inter-domain
- routing in the Pip near-term architecture is path-vector.
- Because of this, the Pip Header Server does not obtain enough
- information from inter-domain routing to form a policy route.
- When the technology to do this matures, it can be installed into
- Pip Header Servers.)
-
- The inter-domain routing information is optional. If it is used,
- then probably a Pip Header Server is necessary, to limit this
- information to a small number of systems.
-
- There may also be arbitrary policy information available to the Pip
- header formation function. This architecture does not specify any
- such information.
-
- The Pip header formation function then goes through a process of
- forming an ordered list of source/destination Pip Addresses to use.
- The ordering is based on knowledge of the application service
- requirements, the service provided by the source providers, guesses
- or learned information about the service provided by the destination
- providers or by source/destination provider pairs, and the cost of
- using source providers to reach destination providers. It is assumed
- that the sophistication of forming the ordered list will grow as
- experienced is gained with internet commercialization and real-time
- services.
-
- The Pip Header formation function then returns the ordered pairs of
- source and destination addresses to the source host in the PHP
- response message, along with an indication of what kind of exit
- routing to use with each pair. Any additional information, such as
- PDN Address, is also returned. With this information, the source
- host can now establish communications and properly respond to PCMP
- messages. Based on information received from PCMP messages,
-
-
-
- Francis [Page 26]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- particularly PCMP Packet Not Delivered messages but also Mobile Host
- messages, the host is able to choose appropriately from the ordered
- list.
-
- Note that if Pip evolves to the point where the Transit Part of the
- Pip header is no longer compatible with the current Transit Part, and
- the querying host has not been updated to understand the new Transit
- Part, then the PHP response message contains a bit map of the Transit
- Part. The host puts this bit map into the Transit Part of the
- transmitted Pip header even though it does not understand the
- semantics of the Transit Part. The Host Version field indicates to
- the Pip Header Server what kinds of transit parts the host can
- understand.
-
- 9.2 Pip Header Protocol (PHP)
-
- The Pip Header Protocol (PHP) is a simple query/response protocol
- used to exchange information between the Pip host and the Pip Header
- Server [6]. In the query, the Pip host includes (among other things)
- the domain name of the destination it wishes to send Pip packets to.
- (Thus, the PHP query serves as a substitute for the DNS query.)
-
- The PHP query also contains 1) User Access Restriction Classes, 2)
- Application Types, and 3) host version. The host version tells the
- Pip Header Server what features are installed in the host. Thus, the
- Pip Header Server is able to determine if the host can format its own
- Pip header based on DNS information, or whether the Pip Header Server
- needs to do it on behalf of the host. In the future, the PHP query
- will also contain desired TOS (possibly in lieu of Application Type).
- (Note that this information could come from the application. Thus,
- the application interface to PHP (the equivalent of gethostbyname())
- must pass this information.)
-
- 9.3 Application Interface
-
- In order for a Pip host to generate the information required in the
- PHP query, there must be a way for the application to convey the
- information to the PHP software. The host architecture for doing
- this is as follows.
-
- A local "Pip Header Client" (the source host analog to the Pip Header
- Server) is called by the application (instead of the current
- gethostbyname()). The application provides the Pip Header Client
- with either the destination host domain name or the destination host
- Pip ID, and other pertinent information such as user access
- restriction class and TOS. The Pip Header Client, if it doesn't have
- the information cached locally, queries the Pip Header Server and
- receives an answer. (Remember that the Pip Header Server can be co-
-
-
-
- Francis [Page 27]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- resident with the host.)
-
- Once the Pip Header Client has determined what the Pip header(s) are,
- it assigns a local handle to the headers, returns the handle to the
- application, and configures the Pip packet processing engine with the
- handle and related Pip Headers. The application then issues packets
- to the Pip layer (via intervening layers such as transport) using the
- local handle.
-
- 10. Routing Algorithms in Pip
-
- This section discusses the routing algorithm for use with
- (hierarchical) Pip Addresses.
-
- The architecture for operating routing algorithms in Pip reflects the
- clean partitioning of routing contexts in the Pip header. Thus,
- routing in the Pip architecture is nicely modularized.
-
- Within the Hierarchical Pip Address, there are multiple hierarchical
- levels. Wherever two routers connect, or two levels interface
- (either in a single router or between routers), two decisions must be
- made: 1) what information should be exchanged (that is, what of one
- side's routing table should be propagated to the other side), and 2)
- what routing algorithm should be used to exchange the information?
- The first decision is discussed in section 10.1 below (Routing
- Information Filtering). The latter decision is discussed here.
-
- Conceptually, and to a large extent in practice, the routing
- algorithms at each level are cleanly partitioned. This partition is
- much like the partition between "egp" and "igp" level routing in IP,
- but with Pip it exists at each level of the hierarchy.
-
- At the top-level of the Pip Address hierarchy, a path-vector routing
- algorithm is used. Path-vector is more appropriate at the top level
- than link-state because path-vector does not require agreement
- between top-level entities (providers) on metrics in order to be
- loop-free. (Agreement between the providers is likely to result in
- better paths, but the Pip Architecture does not assume such
- agreement.)
-
- The top-level path-vector routing algorithm is based on IDRP, but
- enhanced to handle Pip addresses and Pip idiosyncrasies such as the
- Routing Context. At any level below the top level, it is a local
- decision as to what routing algorithm technology to run. However,
- the path-vector routing algorithm is generalized so that it can run
- at multiple levels of the Pip Address hierarchy. Thus, a lower level
- domain can choose to take advantage of the path-vector algorithm, or
- run another, such as a link-state algorithm. The modified version of
-
-
-
- Francis [Page 28]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced
- "milpiv").
-
- Normally, information is exchanged between two separate routing
- algorithms by virtue of the two algorithms co-existing in the same
- router. For instance, a border router is likely to participate in an
- exchange of routing information with provider routers, and still run
- the routing algorithm of the internal routers. If the two algorithms
- are different routing technologies (for instance, link-state versus
- distance-vector) then internal conversion translates information from
- one routing algorithm to the form of the other.
-
- In some cases, however, two routing algorithms that exchange
- information will exist in different routers, and will have to
- exchange information over a link. If these two algorithms are
- different technologies, then they need a common means of exchanging
- routing information. While strictly speaking this is a local matter,
- MLPV can also serve as the interface between two disparate routing
- algorithms. Thus, all routers should be able to run MLPV, if for no
- other reason than to exchange information with other, perhaps
- proprietary, routing protocols.
-
- MLPV is designed to be extendible with regards to the type of routes
- that it calculates. It uses the Pip Object parameter identification
- number space to identify what type of route is being advertised and
- calculated [9]. Thus, to add new types of routes (for instance, new
- types of service), it is only necessary to configure the routers to
- accept the new route type, define metrics for that type, and criteria
- for preferring one route of that type over another.
-
- 10.1 Routing Information Filtering
-
- Of course, the main point behind having hierarchical routing is so
- that information from one part of the hierarchy can be reduced when
- passed to another. In general, reduction (in the form of
- aggregation) takes place when passing information from the bottom of
- the hierarchy up. However, Pip uses tunneling and exit routing to,
- if desired, allow information from the top to be reduced when it goes
- down.
-
- When two routers become neighbors, they can determine what
- hierarchical levels they have in common by comparing Pip Addresses.
- For instance, if two neighbor routers have Pip Addresses 1.2.3,4 and
- 1.2.8,9.14 respectively, then they share levels 0 and 1, and are
- different at levels below that. (0 is the highest level, 1 is the
- next highest, and so on.) As a general rule, these two routers
- exchange level 0, level 1, and level 2 routing information, but not
- level 3 or lower routing information. In other words, both routers
-
-
-
- Francis [Page 29]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- know how to route to all things at the top level (level 0), how to
- route to all level 1 things with "1" as the level 0 prefix, and how
- to route to all level 2 things with "1.2" as the level 1 prefix.
-
- In the absence of other instructions, two routers will by default
- exchange information about all levels from the top down to the first
- level at which they have differing Pip Addresses. In practice,
- however, this default exchange is as likely to be followed as not.
- For instance, assume that 1.2.3,4 is a provider router, and
- 1.2.8,9.14 is a subscriber router. (Note that 1.2.8 is the prefix
- given the subscriber by the provider, thus the metalevel boundary
- indicated by the comma.) Assume also that the subscriber network is
- using destination-oriented transit-driven exit routing (see section
- 8.1). Finally, assume that router 1.2.8,9.14 is the subscriber's
- only entry point into provider 1 (other routers provide entry points
- to other providers).
-
- In this case, 1.2.8,9.14 does not need to know about level 2 or level
- 1 areas in the provider (that is, it does not need to know about
- 1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on). Thus, 1.2.8,9.14
- should be configured to inform 1.2.3,4 that it does not need level 1
- or 2 information.
-
- As another example, assume still that 1.2.3,4 is a provider and
- 1.2.8,9.14 is a subscriber. However, assume now that the subscriber
- network is using host-driven exit routing. In this case, the
- subscriber does not even need to know about level 0 information,
- because all exit routing is directed to the provider of choice, and
- having level 0 information therefore does not influence that choice.
-
- 11. Transition
-
- The transition scheme for Pip has two major components, 1)
- translation, and 2) encapsulation. Translation is required to map
- the Pip Address into the IP address and vice versa. Encapsulation is
- used for one Pip router (or host) to exchange packets with another
- Pip router (or host) by tunneling through intermediate IP routers.
-
- The Pip transition scheme is basically a set of techniques that
- allows existing IP "stuff" and Pip to coexist, but within the
- limitations of IP address depletion (though not within the
- limitations of IP scaling problems). By this I mean that an IP-only
- host can only exchange packets with other hosts in a domain where IP
- numbers are unique. Initially this domain includes all IP hosts, but
- eventually will include only hosts within a private domain. The IP
- "stuff" that can exist includes 1) whole IP domains, 2) individual IP
- hosts, 3) IP-oriented TCPs, and 4) IP-oriented applications.
-
-
-
-
- Francis [Page 30]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 11.1 Justification for Pip Transition Scheme
-
- Note that all transition to a bigger address require translation. It
- cannot be avoided. The major choices one must make when deciding on
- a translation scheme are:
-
- 1. Will we require a contiguous infrastructure consisting of the new
- protocol, or will we allow tunneling through whatever remains of
- the existing IP infrastructure at any point in time?
-
- 2. Will we allow global connectivity between IP machines after IP
- addresses are no longer globally unique, or not? (In other words,
- will we use a NAT scheme or not? [15])
-
- Concerning question number 1; while it is desirable to move as
- quickly as possible to a contiguous Pip (or SIP or whatever)
- infrastructure, especially for purposes of improved scaling, it is
- fantasy to think that the whole infrastructure will cut over to Pip
- quickly. Furthermore, during the testing stages of Pip, it is highly
- desirable to be able to install Pip in any box anywhere, and by
- tunneling through IP, create a virtual Pip internet. Thus, it seems
- that the only reasonable answer to question number 1 is to allow
- tunneling.
-
- Concerning question number 2; it is highly desirable to avoid using a
- NAT scheme. A NAT (Network Address Translation) scheme is one
- whereby any two IP hosts can communicate, even though IP addresses
- are not globally unique. This is done by dynamically mapping non-
- unique IP addresses into unique ones in order to cross the
- infrastructure. NAT schemes have the problems of increased
- complexity to maintain the mappings, and of translating IP addresses
- that reside within application data structures (such as the PORT
- command in FTP).
-
- This having been said, it is conceivable that the new protocol will
- not be far enough along when IP addresses are no longer unique, and
- therefore a NAT scheme becomes necessary. It is possible to employ a
- NAT scheme at any time in the future without making it part of the
- intended transition scheme now. Thus, we can plan for a NATless
- transition now without preventing the potential use of NAT if it
- becomes necessary.
-
- 11.2 Architecture for Pip Transition Scheme
-
- The architecture for Pip Transition is that of a Pip infrastructure
- surrounded by IP-only "systems". The IP-only "systems" surrounding
- Pip can be whole IP domains, individual IP hosts, an old TCP in an
- otherwise Pip host, or an old application running on top of a Pip-
-
-
-
- Francis [Page 31]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- smart TCP.
-
- The Pip infrastructure will initially get its internal connectivity
- by tunneling through IP. Thus, any Pip box can be installed
- anywhere, and become part of the Pip infrastructure by configuration
- over a "virtual" IP. Of course, it is desirable that Pip boxes be
- directly connected to other Pip boxes, but very early on this is the
- exception rather than the rule.
-
- Two neighbor Pip systems tunneling through IP simply view IP as a
- "link layer" protocol, and encapsulate Pip over IP just as they would
- encapsulate Pip over any other link layer protocol. In particular,
- the hop-count field of Pip is not copied into the Time-to-Live field
- of IP. There is no automatic configuration of neighbor Pip systems
- over IP. Manual configuration (and careful "virtual topology"
- engineering) is required. Note that ICMP messages from a IP router
- in a tunnel is not translated into a PCMP message and sent on. ICMP
- messages are sinked at the translating router at the head of the
- tunnel. The information learned from such ICMP messages, however,
- may be used to determine unreachability of the other end of the
- tunnel, and may there result in PCMP message on later packets.
-
- In the remainder of this section, we do not distinguish between a
- virtual Pip infrastructure on IP, and a pure Pip infrastructure.
-
- Given the model of a Pip infrastructure surrounded by IP, there are 5
- possible packet paths:
-
- 1. IP - IP
-
- 2. IP - Pip - IP
-
- 3. IP - Pip
-
- 4. Pip - IP
-
- 5. Pip - Pip
-
- The first three paths involve packets that originate at IP-only
- hosts. In order for an IP host to talk to any other host (IP or
- not), the other host must be addressable within the context of the IP
- host's 32-bit IP address. Initially, this "IP-unique" domain will
- include all IP hosts. When IP addresses become no longer unique, the
- IP-unique domain will include a subset of all hosts. At a minimum,
- this subset will include those hosts in the IP-host's private domain.
- However, it makes sense also to arrange for the set of all "public"
- hosts, basically anonymous ftp servers and mail gateways, to be in
- this subset. In other words, a portion of IP address space should be
-
-
-
- Francis [Page 32]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- set aside to remain globally unique, even though other parts of the
- address space are being reused.
-
- 11.3 Translation between Pip and IP packets
-
- Paths 2 and 4 involve translation from Pip to IP. This translation
- is straightforward, as all the information needed to create the IP
- addresses is in the Pip header. In particular, Pip IDs have an
- encoding that allows them to contain an IP address (again, one that
- is unique within an IP-unique domain). Whenever a packet path
- involves an IP host on either end, both hosts must have IP addresses.
- Thus, translating from Pip to IP is just a matter of extracting the
- IP addresses from the Pip IDs and forming an IP header.
-
- Translating from an IP header to a Pip header is more difficult,
- because the 32-bit IP address must be "translated" into a 64-bit Pip
- ID and a Pip Address. There is no algorithm for making this
- translation. A table mapping IP addresses (or, rather, network
- numbers) to Pip IDs and Pip Addresses is required. Since such a
- table must potentially map every IP address, we choose to use dynamic
- discovery and caching to maintain the table. We choose also to use
- DNS as the means of discovering the mappings.
-
- Thus, DNS contains records that map IP address to Pip ID and Pip
- Address. In the case where the host represented by the DNS record is
- a Pip host (packet path 3), the Pip ID and Pip Address are those of
- the host. In the case where the host represented by the DNS record
- is an IP-only host (packet paths 2 and 4), the Pip Address is that of
- the Pip/IP translating gateway that is used to reach the IP host.
- Thus, an IP-only domain must at least be able to return Pip
- information in its DNS records (or, the parent DNS domain must be
- able to do it on behalf of the child).
-
- With paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating
- gateway (IP to Pip) makes the DNS query. It stores the IP packet
- while waiting for the answer. The query is an inverse address (in-
- addr) using the destination IP address. The translating gateway can
- cache the record for an arbitrarily long period, because if the
- mapping ever becomes invalid, a PCMP Invalid Address message flushes
- the cache entry.
-
- In the case of path 4 (Pip-IP), however, the Pip Address of the
- translating gateway is returned directly to the source host--
- piggybacked on the DNS record that is normally returned. Thus this
- scheme incurs only a small incremental cost over the normal DNS
- query.
-
-
-
-
-
- Francis [Page 33]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 11.4 Translating between PCMP and ICMP
-
- The only ICMP/PCMP messages that are translated are the Destination
- Unreachable, Echo, and PTMU Exceeded messages. The portion of the
- offending IP/Pip header that is attached to the ICMP/PCMP message is
- not translated.
-
- 11.5 Translating between IP and Pip Routing Information
-
- It is not necessary to pass IP routing information into the Pip
- infrastructure. The mapping of IP address to Pip Address in DNS
- allows Pip to find the appropriate gateway to IP in the context of
- Pip addresses only.
-
- It is impossible to pass Pip routing information into IP routers,
- since IP routers cannot understand Pip addresses. IP domains must
- therefore use default routing to reach IP/Pip translators.
-
- 11.6 Old TCP and Application Binaries in Pip Hosts
-
- A Pip host can be expected to have an old TCP above it for a long
- time to come, and a new (Pip-smart) TCP can be expected to have old
- application binaries running over it for a long time to come. Thus,
- we must have some way of insuring that the TCP checksum is correctly
- calculated in the event that one or both ends is running Pip, and one
- or both ends has an old TCP binary. In addition, we must arrange to
- allow applications to interface with TCP using a 32-bit "address"
- only, even though those 32 bits get locally translated into Pip
- Addresses and IDs.
-
- As stated above, in all cases where a Pip host is talking to an IP-
- only host, the Pip host has a 32-bit IP address. This address is
- embedded in the Pip ID such that it can be identified as an IP
- address from inspection of the Pip ID alone.
-
- The TCP pseudo-header is calculated using the Payload Length and
- Protocol fields, and some or all of the Source and Dest Pip IDs. In
- the case where both Source and Dest Pip IDs are IP-based, only the
- 32-bit IP address is included in the pseudo-header checksum
- calculation. Otherwise, the full 64 bits are used. (Note that using
- the full Payload Length and Protocol fields does not fail when old
- TCP binaries are being used, because the values for those fields must
- be within the 16-bit and 8-bit limits for TCP to correctly operate.)
-
- The reason for only using 32 bits of the Pip ID in the case of both
- ends using an IP address is that an old TCP will use only 32 bits of
- some number to form the pseudo-header. If the entire 64 bits of the
- Pip ID were used, then there would be cases where no 32-bit number
-
-
-
- Francis [Page 34]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- could be used to insure that the correct checksum is calculated in
- all cases.
-
- Note that in the case of an old TCP on top of Pip, "Pip" (actually, a
- Pip daemon) must create a 32-bit number that can both be used to 1)
- allow the Pip layer to correctly associate a packet from the TCP
- layer with the right Pip header, and 2) cause the TCP layer to
- calculate the right checksum. (This number is created when the
- application initiates a DNS query. A Pip daemon intervenes in this
- request, calculates a 32 bit number that the application/TCP can use,
- and informs the Pip layer of the mapping between this 32 bit number
- and the full Pip header.)
-
- When the destination host is an IP only host, then this 32-bit number
- is nothing more than the IP address. When the destination host is a
- Pip host, then this 32-bit number is some number generated by Pip to
- "fool" the old TCP into generating the right checksum. This 32-bit
- number can normally be the same as the lower 32 bits of the Pip ID.
- However, it is possible that two or more active TCP connections is
- established to different hosts whose Pip IDs have the same lower 32
- bits. In this case, the Pip layer must generate a different 32-bit
- number for each connection, but in such a way that the sum of the two
- 16-bit components of the 32-bit numbers are the same as the sum of
- the two 16-bit components of the lower 32 bits of the Pip IDs.
-
- In the case where an old Application wants to open a socket using an
- IP address handed to it (by the user or hard-coded), and not using a
- domain name, then it must be assumed that this IP address is valid
- within the IP-unique domain. To form a Pip ID out of this 32-bit
- number, the host appends the high-order 24 bits of its own Pip ID,
- plus the IP-address-identifier-byte value, to the 32-bit IP address.
-
- 11.7 Translating between Pip Capable and non-Pip Capable DNS Servers
-
- In addition to transitioning "Pip-layer" packets, it is necessary to
- transition DNS from non-Pip capable to Pip capable. During
- transition there will be name servers in DNS that only understand IP
- queries and those that understand both Pip and IP queries. This
- means there must be a mechanism for Pip resolvers to detect whether a
- name server is Pip capable, and vice versa. Also, a name server, if
- it provides recursive service, must be able to translate Pip requests
- to IP requests. (Pip-capable means a name server understands Pip and
- existing IP queries. It does not necessarily mean the name server
- uses the Pip protocol to communicate.)
-
- New resource records have been defined to hold Pip identifiers and
- addresses, and other information [1]. These resource records must be
- queried using a new opcode in the DNS query packet header. Existing
-
-
-
- Francis [Page 35]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- resource records can be queried using both the old and new header
- formats. Name servers that are not Pip-capable will respond with a
- format error to queries with the new opcode. Thus, a resolver can
- determine dynamically whether a name server is Pip-capable, by
- sending it a Pip query and noting the response. This only need be
- done once, when querying a server for the "first" time, and the
- outcome can be cached along with the name server's address.
-
- Using a new opcode for making Pip queries also helps name servers
- determine whether a resolver is Pip-capable (it is not always not
- obvious from the type of query made since many queries are common to
- to IP and Pip). Determining whether a resolver is Pip-capable is
- necessary when responding with address information that is not
- explicitly requested by the query. An important example of this is
- when a name server makes a referral to another name server in a
- response: if the request comes from a Pip resolver, name server
- addresses will be returned as Pip identifier/address resource
- records, otherwise the addresses will be returned as IP A resource
- records.
-
- Those servers that are Pip-capable and provide recursive service must
- translate Pip requests to IP requests when querying an IP name
- server. For most queries, this will just mean modifying the opcode
- value in the query header to reflect an IP query, rather than a Pip
- query. (Most queries are identical in IP and Pip.) Other queries,
- notably the query for Pip identifier/address information, must be
- translated into its IP counterpart, namely, an IP A query. On
- receipt of an answer from an IP name server, a Pip name server must
- translate the query header and question section back to its original,
- and format the answer appropriately. Again, for most queries, this
- will be a trivial operation, but responses containing IP addresses,
- either as a result of an explicit query or as additional information,
- must be formatted to appear as a valid Pip response.
-
- Pip-capable name servers that provide recursive name service should
- also translate IP address requests into Pip identifier/address
- requests when querying a Pip-capable name server. (A host's IP
- address can be deduced from the host's Pip identifier.) This enables
- a Pip-capable name server to cache all relevant addressing
- information about a Pip host in the first address query concerning
- the host. Caching partial information is undesirable since the name
- server, using the current DNS caching strategy, would return only the
- cached information on a future Pip request, and IP, rather than Pip,
- would be used to communicate with the destination host.
-
-
-
-
-
-
-
- Francis [Page 36]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 12. Pip Address and ID Auto-configuration
-
- One goal of Pip is to make networks as easy to administer as
- possible, especially with regards to hosts. Certain aspects of the
- Pip architecture make administration easier. For instance, the ID
- field provides a network layer "anchor" around which address changes
- can be administered.
-
- This section discusses three aspects of autoconfiguration; 1)
- domain-wide Pip Address prefix assignment, 2) host Pip Address
- assignment, and 3) host Pip ID assignment.
-
- 12.1 Pip Address Prefix Administration
-
- A central premise behind the use of provider-rooted hierarchical
- addresses is that domain-wide address prefix assignment and re-
- assignment is straight-forward. This section describes that process.
-
- Pip Address prefix administration limits required manual prefix
- configuration to DNS and border routers. This is the minimum
- required manual configuration possible, because both border routers
- and DNS must be configured with prefix information for other reasons.
- DNS must be configured with prefix information so that it can reply
- to address queries. DNS files are structured so that the prefix is
- administered in only one place (that is, every host record does not
- have to be changed to create a new prefix). Border routers must be
- configured with prefix information in order to advertise exit routes
- internally.
-
- Note in particular that no internal (non-border) routers or hosts
- need ever be manually configured with any externally derived
- addressing information. All internal routers that are expected to
- fall under a common provider-prefix must, however, be configured with
- a "group ID" taken from the Pip ID space. (This group ID is not a
- multicast ID per se. Rather, it is an identifier that allows prefix
- updates to be targetted to a specific set of routers.)
-
- Each border router is configured with the following information.
-
- 1. The type of exit routing for the domain. This tells the border
- router whether or not it needs to advertise external routes
- internally.
-
- 2. The address prefix of the providers that the border is directly
- connected to. This prefix information includes any metalevel
- boundaries above the subscriber/provider metalevel boundary
- (called simply the subscriber metalevel).
-
-
-
-
- Francis [Page 37]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 3. Other information about the provider (provider name, type, user
- access restriction classes).
-
- 4. A list of common-provider-prefix group IDs that should receive the
- auto-configuration information. (The default is that only systems
- that share a group ID with the border router will receive the
- information.)
-
- This information is injected into the intra-domain routing algorithm.
- It is automatically spread to all routers indicated by the group ID
- list. This way, the default behavior is for the information to be
- automatically constrained to the border router's "area".
-
- When a non-border router receives this information, it 1) records the
- route to the providers in its forwarding table, and 2) advertises the
- information to hosts in the router discovery protocol [8]. Thus
- hosts learn not only their complete address, but also information on
- how to do exit routing and on how to choose source addresses.
-
- 12.2 Host Autoconfiguration
-
- There are three phases of host autoconfiguration:
-
- 1. The host locally creates a flat unique Pip ID (probably globally
- unique but at least unique on the attached subnet).
-
- 2. The host learns its Pip Addresses.
-
- 3. The host optionally obtains a hierarchical, organizationally
- meaningful Pip ID and a domain name from a Pip ID/domain name
- assignment service. This service updates DNS.
-
- Item three is optional. If Pip ID and domain name assignment
- services are not installed, then the host must obtain its domain name
- and, if necessary, Pip ID, from static configuration. Each of the
- three phases are described below.
-
- 12.2.1 Host Initial Pip ID Creation
-
- When a host boots, it can form an ID based only on local information.
- If the host has an IEEE 802 number, either from an IEEE 802 interface
- or from an internal identifier, then it can create a globally unique
- Pip ID from the IEEE 802 Pip ID type [4]. Otherwise, the host can
- create an ID from the IEEE 802 space using its subnet (link layer)
- address. This latter ID is only guaranteed to be locally unique.
-
-
-
-
-
-
- Francis [Page 38]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 12.2.2 Host Pip Address Assignment
-
- Unless a host does not wish to use ID-tailed Pip Addresses (see
- section 4.1.2), host Pip Address assignment is trivial. (The near-
- term Pip Architecture doesn't specify a means for a host to obtain a
- non-ID-tailed Pip Address.) When a host attaches to a subnet, it
- learns the Pip Address of the attached routers through router
- discovery.
-
- The host simply adopts these Pip Addresses as its own. The Pip
- Address gets a packet to the host's subnet, and the host's Pip ID is
- used to route across the subnet. When the routers advertise new
- addresses (for instance, because of a new provider), the host adopts
- the new addresses.
-
- 12.2.3 Pip ID and Domain Name Assignment
-
- Once the host has obtained its Pip Addresses and an at-least-
- locally-unique Pip ID, it can exchange packets with an ID/Domain Name
- (ID/DN) assignment service. If the host locally created a globally
- unique Pip ID (using an IEEE 802 number), and the organization it
- belongs to does not use organizationally structured Pip IDs (which
- should normally be the case) then it only needs to obtain a domain
- name. The ID/DN assignment service is reachable at a well-known
- anycast address [4]. Thus, the host is able to start exchanging
- packets with the ID/DN assignment service without any additional
- configuration.
-
- If there is no ID/DN assignment service available, then the host must
- obtain it's organizational ID or DNS name in a non-automatic way. If
- the ID/DN assignment service is down, the host must temporarily
- suffice with just a Pip ID and Address. The host can periodically
- try to reach the ID/DN assignment service.
-
- The ID/DN assignment service must coordinate with DNS. When the
- ID/DN assignment service creates a new ID or domain name to assign to
- a new host, it must know which IDs and domain names are available for
- assignment. It must also update DNS with the new information.
-
- The design of this service is left for further study.
-
-
-
-
-
-
-
-
-
-
-
- Francis [Page 39]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 13. Pip Control Message Protocol (PCMP)
-
- The Pip analog to ICMP is PCMP [7]. The near-term Pip architecture
- defines the following PCMP messages:
-
- 1. Local Redirect
-
- 2. Packet Not Delivered
-
- 3. Echo
-
- 4. Parameter Problem
-
- 5. Router Discovery
-
- 6. PMTU Exceeded
-
- 7. Provider Redirect
-
- 8. Reformat Transit Part
-
- 9. Unknown Parameter
-
- 10. Host Mobility
-
- 11. Exit PDN Address
-
- The Local Redirect, Echo, and Parameter Problem PCMP messages operate
- almost identically to their ICMP counterparts.
-
- The Packet Not Delivered PCMP message serves the role of ICMP's
- Destination Unreachable. The Packet Not Delivered, has two major
- differences. First, it is more general in that it indicates the
- hierarchy level of unreachability (rather than explicit host, subnet,
- network unreachability as with IP). Second, it indicates when an
- address is known to be invalid, thus allowing for more intelligent
- use of DNS (see section 6.2).
-
- The Router Discovery PCMP message operates as ICMP's, with the
- exception that a host derives its Pip Address from it.
-
- The PMTU Exceeded message operates as ICMP's, with the exception that
- the Pip header size of the offending Packet is also given. This
- allows the source host transport to determine how much smaller the
- packet PMTU should be from the advertised subnet PMTU. Note that if
- an occasional option, such as the PDN Address option, needs to be
- attached to one of many packets, and that this option makes the
- packet larger than the PMTU, then it is not necessary to modify the
-
-
-
- Francis [Page 40]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- MTU coming from transport. Instead, that packet can be fragmented by
- the host's Pip forwarding engine. (Pip specifies
- fragmentation/reassembly for hosts but not for routers. The
- fragmentation information is in a Pip Option.)
-
- The Provider Redirect, Invalid Address, Reformat Transit Part,
- Unknown Parameter, Host Mobility, and Exit PDN Address PCMP messages
- are new.
-
- The Provider Redirect PCMP message is used to inform the source host
- of a preferable exit provider to use when provider-rooted, transit-
- driven exit routing is used (see section 8.1).
-
- The Invalid Address PCMP message is used to inform the source host
- that none of the IDs of the destination host match that of the Pip
- packet. The purpose of this message is to allow for authoritative
- DNS requests (see section 6.2).
-
- The Reformat Transit Part PCMP message has both near-term Pip
- architecture functions and evolution functions. Near-term, the
- Reformat Transit Part PCMP message is used to indicate to the source
- whether it has too few or too many layers of address in the Routing
- Directive (see section 8.2). Long-term, the Reformat Transit Part
- PCMP message is able to arbitrarily modify the transit part
- transmitted by the host, as encoded by a bit string.
-
- The Unknown Parameter PCMP message is used to inform the source host
- that the router does not understand a parameter in either the
- Handling Directive, the Routing Context, or the Transit Options. The
- purpose of this message is to assist evolution (see section 16.1).
-
- The Host Mobility PCMP message is sent by a host to inform another
- host (for instance, the host's Mobile Address Server) that it has a
- new address (see section 14). The main use of this packet is for
- host mobility, though it can be used to manage any address changes,
- such as because of a new prefix assignment.
-
- The Exit PDN Address PCMP message is used to manage the function
- whereby the source host informs the PDN entry router of the PDN
- Address of the exit PDN system (see section 15).
-
- When a router needs to send a PCMP message, it sends it to the source
- Pip Address. If the Pip header is in a tunnel, then the PCMP message
- is sent to the router that is the source of the tunnel. Depending on
- the situation, this may result in another PCMP message from the
- source of the tunnel to the true source (for instance, if the source
- of the tunnel finds that the dest of the tunnel can't be reached, it
- may send a Packet Not Delivered to the source host).
-
-
-
- Francis [Page 41]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 14. Host Mobility
-
- Depending on how security conscience a host is, and what security
- mechanisms a host has available, mobility can come from Pip "for
- free". If a host is willing to accept a packet by just looking at
- source and destination Pip ID, and if the host simply records the
- source Pip Address on any packet it receives as the appropriate
- return address to the source Pip ID, then mobility comes
- automatically.
-
- That is, when a mobile host gets a new Pip Address, it simply puts
- that address into the next packet it sends. When the other host
- receives it, it records the new Pip Address, and starts sending
- return packets to that address. The security aspect of this is that
- this type of operation leads to an easy way to spoof the (internet
- level) identity of a host. That is, absent any other security
- mechanisms, any host can write any Pip ID into a packet. (Cross-
- checking a source Pip ID against the source Pip Address at least
- makes spoofing of this sort as hard as with IP. This is discussed
- below.)
-
- The above simple host mobility mechanism does not work in the case
- where source and destination hosts obtain new Pip Addresses at the
- same time and the old Pip addresses no longer work, because neither
- is able to send its new address information directly to the other.
- Furthermore, if a host wishes to be more secure about authenticating
- the source Pip ID of a packet, then the above mechanism also is not
- satisfactory. In what follows, the complete host mobility mechanism
- is described.
-
- Pip uses the Mobile Host Server and the PCMP Host Mobility message to
- manage host mobility;
-
- The Mobile Host Server is a non-mobile host (or router acting as a
- host) that keeps track of the active address of a mobile host. The
- Pip ID and Address of the Mobile Host Server is configured into the
- mobile host, and in DNS. When a host X obtains information from DNS
- about a host Y, the Pip ID and Address of host Y's Mobile Host Server
- is among the information. (Also among the information is host Y's
- "permanent" address, if host Y has one. If host Y is so mobile that
- it doesn't have a permanent address, then no permanent address is
- returned by DNS. In particular, note that DNS is not intended to
- keep track of a mobile host's active address.)
-
- Given the destination host's (Y) permanent ID and Address, and the
- Mobile Host Server's permanent IDs and Addresses, the source host (X)
- proceedes as follows. X tries to establish communications with Y
- using one of the permanent addresses. If this fails (or if at any
-
-
-
- Francis [Page 42]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- time X cannot contact Y), X sends a PCMP Mobile Host message to the
- Mobile Host Server requesting the active address for Y. (Note that X
- can determine that it cannot contact Y from receipt of a PCMP
- Destination Unreachable or a PCMP Invalid Address message.)
-
- The Mobile Host Server responds to X with the active Pip Addresses of
- Y. (Of course, Y must inform its Mobile Host Server(s) of its active
- Pip Addresses when it knows them. This also is done using the PCMP
- Mobile Host message. Y also informs any hosts that it is actively
- communicating with, using either a regular Pip packet or with a PCMP
- Mobile Host message. Thus, usually X does not need to contact the
- Mobile Host Server to track Y's active address.)
-
- If the address that X already tried is among those returned by Y,
- then the source host has the option of either 1) continuing to try
- the same Pip Address, 2) trying another of Y's Pip Addresses, 3)
- waiting and querying the Mobile Host Server again, or 4) giving up.
-
- If the Mobile Host Server indicates that Y has new active Pip
- Addresses, then X chooses among these in the same manner that it
- chooses among multiple permanent Pip Addresses, and tries to contact
- Y.
-
- 14.1 PCMP Mobile Host message
-
- There are two types of PCMP Mobile Host messages, the query and the
- response. The query consists of the Pip ID of the host for which
- active Pip Address information is being requested.
-
- The response consists of a Pip ID, a sequence number, a set of Pip
- Addresses, and a signature field. The set of Pip Addresses includes
- all currently usable addresses of the host indicated by the Pip ID.
- Thus, the PCMP Mobile Host message can be used both to indicate a
- newly obtained address, and to indicate that a previous address is no
- longer active (by that addresses' absence in the set).
-
- The sequence number indicates which is the most recent information.
- It is needed to deal with the case where an older PCMP Mobile Host
- response is received after a newer one.
-
- The signature field is a value that derives from encrypting the
- sequence number and the set of Pip Addresses. For now, the
- encryption algorithms used, how to obtain keys, and so on are for
- further study.
-
-
-
-
-
-
-
- Francis [Page 43]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- 14.2 Spoofing Pip IDs
-
- This section discusses host mechanisms for decreasing the probability
- of Pip ID spoofing. The mechanisms provided in this version of the
- near-term Pip architecture are no more secure than DNS itself. It is
- hoped that mechanisms and the corresponding infrastructure needed for
- better internetwork layer security can be installed with whatever new
- IP protocol is chosen.
-
- After a host makes a DNS query, it knows:
-
- 1. The destination host's Pip ID,
-
- 2. The destination host's permanent Pip Addresses, and
-
- 3. The destination host's Mobile Host Server's Pip ID and Addresses.
-
- Note that the DNS query can be a normal one (based on domain name) or
- an inverse query (based on Pip ID or Pip Address, though the latter
- is more likely to succeed, since the Pip ID may be flat and therefore
- not suitable for an inverse lookup). The inverse query is done when
- the host did not initiate the packet exchange, and therefore doesn't
- know the domain name of the remote (initiating) host.
-
- If the destination host is not mobile, then the source host can check
- the source Pip Address, compare it with those received from DNS, and
- reject the packet if it does not match. This gives spoof protection
- equal to that of IP.
-
- If the destination host is mobile and obtains new Pip Addresses, then
- the source host can check the validity of the new Pip Address by
- sending a PCMP Mobile Host query to the Mobile Host Server learned
- from DNS. The set of Pip Addresses learned from the Mobile Address
- Server is then used for subsequent validation.
-
- 15. Public Data Network (PDN) Address Discovery
-
- One of the problems with running Pip (or any internet protocol) over
- a PDN is that of the PDN entry Pip System discovering the PDN Address
- of the appropriate PDN exit Pip System. This problem is solved using
- ARP in small, broadcast LANs because the broadcast mechanism is
- relatively cheap. This solution is not available in the PDN case,
- where the number of attached systems is very large, and where
- broadcast is not available (or is not cheap if it is).
-
- For the case where the domain of the destination host is attached to
- a PDN, the problem is nicely solved by distributing the domain's exit
- PDN Address information in DNS, and then having the source host
-
-
-
- Francis [Page 44]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- convey the exit PDN Address to the PDN entry router in a Pip option.
-
- The DNS of the destination host's domain contains the PDN Addresses
- for the domain. When DNS returns a record for the destination host,
- the record associates zero or more PDN Addresses with each Pip
- Address. There can be more than one PDN address associated with a
- given PDN, and there can be more than on PDN associated with a given
- Pip Address. This latter case occurs when more than one hierarchical
- component of the Pip Address each represents a separate PDN. It is
- expected that in almost all cases, there will be only one (or none)
- PDN associated with any Pip address.
-
- (Note that, while the returned DNS record associates the PDN
- Addresses with a single Pip Address, in general the PDN Address will
- apply to a set of Pip Addresses--those for all hosts in the domain.
- The DNS files are structured to reflect this grouping in the same way
- that a single Pip Address prefix in DNS applies to many hosts.
- Therefore, every individual host entry in the DNS files does not need
- to have separate PDN Addresses typed in with it. This simplifies
- configuration of DNS.)
-
- When the source host sends the first packet to a given destination
- host, it attaches the PDN Addresses, one per PDN, to the packet in an
- option. (Note that, because of the way that options are processed in
- Pip packets, no router other than the entry PDN router need look at
- the option.) When the entry router receives this packet, it
- determines that it is the entry router based on the result of the
- FTIF Chain lookup.
-
- It retrieves the PDN Address from the option, and caches it locally.
- The cache entry can later by retrieved using either the destination
- Pip ID or the destination Pip Address as the cache index.
-
- The entry router sends the source host a PCMP Exit PDN Address
- message indicating that it has cached the information. If there are
- multiple exit PDN Addresses, then the source host can at this time
- inform the entry PDN router of all the PDN addresses. The entry PDN
- router can either choose from these to setup a connection, or cache
- them to recover from the case where the existing connection breaks.
-
- Finally, the entry PDN router delivers the Pip packet (perhaps by
- setting up a connection) to the PDN Address indicated.
-
- When a PDN entry router receives a Pip packet for which it doesn't
- know the exit PDN address (and has no other means of determining it,
- such as shortcut routing), it sends a PCMP Exit PDN Address query
- message to the originating host. This can happen if, for instance,
- routing changes and directs the packets to a new PDN entry router.
-
-
-
- Francis [Page 45]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- When the source host receives the PCMP Exit PDN Address query
- message, it transmits the PDN Addresses to the entry PDN router.
-
- 15.1 Notes on Carrying PDN Addresses in NSAPs
-
- The Pip use of PDN Address carriage in the option or PCP Exit PDN
- Address message solves two significant problems associated with the
- analogous use of PDN Address-based NSAPs.
-
- First, there is no existing agreement (standards or otherwise) that
- the existence of of a PDN Address in an NSAP address implies that the
- identified host is reachable behind the PDN Address. Thus, upon
- receiving such an NSAP, the entry PDN router does not know for sure,
- without explicit configuration information, whether or not the PDN
- Address can be used at the lower layer. Solution of this problem
- requires standards body agreement, perhaps be setting aside
- additional AFIs to mean "PDN Address with topological significance".
-
- The second, and more serious, problem is that a PDN Address in an
- NSAP does not necessarily scale well. This is best illustrated with
- the E.164 address. E.164 addresses can be used in many different
- network technologies--telephone network, BISDN, SMDS, Frame Relay,
- and other ATM. When a router receives a packet with an E.164-based
- NSAP, the E.164 address is in the most significant part of the NSAP
- address (that is, contains the highest level routing information).
- Thus, without a potentially significant amount of routing table
- information, the router does not know which network to send the
- packet to. Thus, unless E.164 addresses are assigned out in blocks
- according to provider network, it won't scale well.
-
- A related problem is that of how an entry PDN router knows that the
- PDN address is meant for the PDN it is attached to or some other PDN.
- With Pip, there is a one-to-one relationship between Pip Address
- prefix and PDN, so it is always known. With NSAPs, it is not clear
- without the potentially large routing tables discussed in the
- previous paragraph.
-
- 16. Evolution with Pip
-
- The fact that we call this architecture "near-term" implies that we
- expect it to evolve to other architectures. Thus it is important
- that we have a plan to evolve to these architectures. The Pip near-
- term architecture includes explicit mechanisms to support evolution.
-
- The key to evolution is being able to evolve any system at any time
- without destroying old functionality. Depending on what the new
- functionality is, it may be immediately useful to any system that
- installs it, or it may not become useful until a significant number
-
-
-
- Francis [Page 46]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- or even a majority of systems install it. None-the-less, it is
- necessary to be able to install it piece-wise.
-
- The Pip protocol itself supports evolution through the following
- mechanisms [2]:
-
- 1. Tunneling. This allows more up-to-date routers to tunnel less
- up-to-date routers, thus allowing for incremental router
- evolution. (Of course, by virtue of encapsulation, tunneling is
- always an evolution option, and indeed tunneling through IP is
- used in the Pip transition. However, Pip's tunneling encoding is
- efficient because it doesn't duplicate header information.)
-
- The only use for Pip tunneling in the Pip near-term architecture
- is to route packets through the internal routers of a transit
- domain when the internal routers have no external routing
- information. It is assumed that enhancements to the Pip
- Architecture that require tunneling will have their own means of
- indicating when forming a tunnel is necessary.
-
- 2. Host independence from routing information. Since a host can
- receive packets without understanding the routing content of the
- packet, routers can evolve without necessarily requiring hosts to
- evolve at the same pace.
-
- In order to allow hosts to send Pip packets without understanding
- the contents of the routing information (in the Transit Part), the
- Pip Header Server is able to "spoon-feed" the host the Pip header.
-
- If the Pip Header Server determines that the host is able to form
- its own Pip header (as will usually be the case with the near-term
- Pip architecture), the Pip Header is essentially a null function.
- It accepts a query from the host, passes it on to DNS, and returns
- the DNS information to the host.
-
- If the Pip Header Server determines that the host is not able to
- form its own Pip header, then the Pip Header Server forms one on
- behalf of the host. In one mode of operation, the Pip Header
- Server gives the host the values of some or all Transit Part
- fields, and the host constructs the Transit Part. This allows for
- evolution within the framework of the current Transit Part. In
- another mode, the Pip Header Server gives the host the Transit
- Part as a simple bit field. This allows for evolution outside the
- framework of the current Transit Part.
-
- In addition to the Pip Header Server being able to spoon-feed the
- host a Transit Part, routers are also able to spoon-feed hosts a
- Transit Part, in case the original Transit Part needs to be
-
-
-
- Francis [Page 47]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- modified, using the PCMP Reformat Transit Part message.
-
- 3. Separation of handling from routing. This allows one aspect to
- evolve independently of the other.
-
- 4. Flexible Handling Directive, Routing Context, and Options
- definition. This allows new handling, routing, and option types
- to be added and defunct ones to be removed over time (see section
- 16.1 below).
-
- 5. Fast and general options processing. Options processing in Pip is
- fast, both because not every router need look at every option, and
- because once a router decides it needs to look at an option, it
- can find it quickly (does not require a serial search). Thus the
- oft-heard argument that a new option can't be used because it will
- slow down processing in all routers goes away.
-
- Pip Options can be thought of as an extension of the Handling
- Directive (HD). The HD is used when the handling type is common,
- and can be encoded in a small space. The option is used otherwise.
- It is possible that a future option will influence routing, and thus
- the Option will be an extension of the RD as well. The RD, however,
- is rich enough that this is unlikely.
-
- 6. Generalized Routing Directive. Because the Routing Directive is
- so general, it is more likely that we can evolve routing and
- addressing semantics without having to redefine the Pip header or
- the forwarding machinery.
-
- 7. Host version number. This number tells what Pip functions a host
- has, such as which PCMP messages it can handle, so that routers
- can respond appropriately to a Pip packet received from a remote
- host. This supports the capability for routers to evolve ahead of
- hosts. (All Pip hosts will at least be able to handle all Pip
- near-term architecture functions.)
-
- The Host version number is also used by the Pip Header Server to
- determine the extent to which the Pip Header Server needs to format
- a header on behalf of the host.
-
- 8. Generalized Route Types. The IDRP/MLPV routing algorithm is
- generic with regards to the types of routes it can calculate.
- Thus, adding new route types is a matter of configuring routers to
- accept the new route type, defining metrics for the new route
- type, and defining criteria for selecting one route of the new
- type over another.
-
-
-
-
-
- Francis [Page 48]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- Note that none of these evolution features of Pip significantly slow
- down Pip header processing (as compared to other internet protocols).
-
- 16.1 Handling Directive (HD) and Routing Context (RC) Evolution
-
- Because the HD and RC are central to handling and routing of a Pip
- packet, the evolution of these aspects deserves more discussion.
-
- Both the HD and the RC fields contain multiple parameters. (In the
- case of the RC, the router treats the RC field as a single number,
- that is, ignores the fact that the RC is composed of multiple
- parameters. This allows for fast forwarding of Pip packets.) These
- HD and RC multiple parameters may be arranged in any fashion (can be
- any length, subject to the length of the HD and RC fields themselves,
- and can fall on arbitrary bit boundaries).
-
- Associated with the HD and RC are "Contents" fields that indicate
- what parameters are in the HD and RC fields, and where they are.
- (The Contents fields are basically version numbers, except that a
- higher "version" number is not considered to supersede a lower one.
- Typical types of parameters are address family, TOS value, queueing
- priority, and so on.)
-
- The Contents field is a single number, the value of which indicates
- the parameter set. The mapping of Contents field value to parameter
- set is configured manually.
-
- The procedure for establishing new HD or RC parameter sets (or,
- erasing old ones) is as follows. Some organization defines the new
- parameter set. This may involve defining a new parameter. If it
- does, then the new parameter is described as a Pip Object. A Pip
- Object is nothing more than a number space used to unambiguously
- identify a new parameter type, and a character string that describes
- it [9].
-
- Thus, the new parameter set is described as a list of Pip Objects,
- and the bit locations in the HD/RC that each Pip Object occupies.
- The organization that defines the parameter set submits it for an
- official Contents field value. (It would be submitted to the
- standards body that has authority over Pip, currently the IAB.) If
- the new parameter set is approved, it is given a Contents value, and
- that value is published in a well known place (an RFC).
-
- Of course, network administrators are free to install or not install
- the new parameter set in their hosts and routers. In the case of a
- new RC parameter set, installation of the new parameter set does not
- necessarily require any new software, because any Pip routing
- protocol, such as IDRP/MLPV, is able to find routes according to the
-
-
-
- Francis [Page 49]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- new parameter set by appropriate configuration of routers.
-
- In the case of a new HD parameter set, however, new software is
- necessary--to execute the new handling.
-
- For new HD and RC parameters sets, systems that do not understand the
- new parameter set can still be configured to execute one of several
- default actions on the new parameter. These default action allow for
- some control over how new functions are introduced into Pip systems.
- The default actions are:
-
- 1. Ignore the unknown parameter,
-
- 2. Set unknown parameter to all 0's,
-
- 3. Set unknown parameter to all 1's,
-
- 4. Silently discard packet,
-
- 5. Discard packet with PCMP Parameter Unknown.
-
- Action 1 is used when it doesn't much matter if previous systems on a
- path have acted on the parameter or not. Actions 2 and 3 are used
- when systems should know whether a previous system has not understood
- the parameter. Actions 4 and 5 are used when something bad happens
- if not all systems understand the new parameter.
-
- 16.1.1 Options Evolution
-
- The evolution of Options is very similar to that of the HD and RC.
- Associated with the Options is an Options Present field that
- indicates in a single word which of up to 8 options are present in
- the Options Part. There is a Contents field associated with the
- Options Present field that indicates which subset of all possible
- options the Options Present field refers to. Contents field values
- are assigned in the same way as for the HD and RC Contents fields.
-
- The same 5 default actions used for the HD and RC also apply to the
- Options.
-
-
-
-
-
-
-
-
-
-
-
-
- Francis [Page 50]
-
- RFC 1621 Pip Near-term Architecture May 1994
-
-
- References
-
- [1] Thomson, F., "Use of DNS with Pip", Work in Progress.
- [2] Francis, P., "Pip Header Processing", Work in Progress.
- [3] Pip Address Assignment Specification, Work in Progress.
- [4] Francis, P., "Pip Identifiers", Work in Progress.
- [5] Pip Assigned Numbers, Work in Progress.
- [6] Pip Header Protocol, Work in Progress.
- [7] Francis, G., "PCMP: Pip Control Message Protocol",
- Work in Progress.
- [8] Pip Router Discovery Protocol, Work in Progress.
- [9] Pip Objects Specification, Work in Progress.
- [10] Rajagopolan, and P. Francis, "The Multi-Level Path Vector
- Routing Scheme", Work in Progress.
- [11] Francis, P., "Pip Address Conventions", Work in Progress.
- [12] Francis, P., "On the Assignment of Provider Rooted Addresses",
- Work in Progress.
- [13] Ballardie, Francis, P., and J. Crowcroft, "Core Based Trees
- (CBT), An Architecture for Scalable Inter-Domain Multicast
- Routing", Work in Progress.
- [14] Franics, P., "Pip Host Operation", Work in Progress.
- [15] Egevang, K., and P. Francis, "The IP Network Address
- Translator (NAT)", RFC 1631, Cray Communications, NTT,
- May 1994.
-
- Notes on the References:
-
- As of the publication of this RFC, a version of [12], titled
- "Comparison of Geographic and Provider-rooted Internet Addressing,"
- was submitted to ISOC INET 94 in Prague. Reference [13] was
- published at ACM SIGCOMM 93 in San Francisco under the title "An
- Architecture for Scalable Inter-Domain Multicast Routing".
-
- Security Considerations
-
- Security issues are not discussed in this memo.
-
- Author's Address:
-
- Paul Francis
- NTT Software Lab
- 3-9-11 Midori-cho Musashino-shi
- Tokyo 180 Japan
-
- Phone: +81-422-59-3843
- Fax +81-422-59-3765
- EMail: francis@cactus.ntt.jp
-
-
-
-
- Francis [Page 51]
-
-